The use of computer networks has become an integral part of the way businesses provide goods and services to their customers. One advantage the use of networks provides is to enable the distribution of applications and the underlying business logic closer to the actual user or customer. This enables these businesses to offer higher levels of service to disparate groups of customers in a wider geographic area than ever before. This has also enabled businesses to allow customers access to the business network, albeit limited, for example, to directly track their purchases. In this case, each customer may have access to standardized or “tailored” application software packages or to custom developed software packages to perform desired operations.
Initially, networks were of a client/server type where the client represented a requestor of services and a server was the provider of the requested servers. However, this network configuration proved to be limiting and multi-tier networks were next developed. The multi-tier network configuration provides improved flexibility and scalability over the client/server network
In the multi-tier network, a middle tier, between a client requesting information and server including a data base, developed that provided services such as transaction monitoring, message servicing and applications services. The middle tier layer thus provided queuing of client requests, application execution and data base staging. The middle tier layer may be further divided into units of different functions to further improve flexibility and scalability. In this case, the middle tier may include applications written in HTML (Hyper-Link Textual Markup Language), which is well-known in the art, for communication with the client and application servers written in C++ or Java programming languages, which are also well-known in the art. To fill the gap between the HTML and C++ applications, an intermediate web server layer may be incorporated to translate messages between the two application layers.
In a further network expansion, a distributed/collaborative enterprise architecture based on an Object Request Broker and/or a Common Object Request Broker Architecture was developed. This enterprise architecture allows for the use, and reuse, of business models on an enterprise-wide scale; an enterprise, in this case, represents a system comprised on multiple business systems or multiple subsystems.
However, as businesses take advantage of their networks and their networks expand, either in a planned manner or by the acquisition of other networks, the number of application packages may increase significantly. In some cases, the state of all the application packages, e.g., “running,” “installed but non-running,” and their locations may not be known or appreciated, particularly for those application packages that may be tailored or those that have narrow usage. In addition, enterprise applications, telecom services and other such services, need not be isolated entities existing on a single host, but rather may be distributed with dependent components present on multiple hosts within their enterprise and sometimes even spanning enterprises. In addition, application components may be updated on some servers and not in others. Hence, while application are composed of software-compatible components, a single definition of the application is not necessarily determinable.
In order to determine the existence of the application and their operating state, it is often required to discover many of the distributed pieces or components and the relationships between them, i.e., the application's “topology,” and further to make a determination that the application has indeed been found. This is not a straightforward task as the variability in configuration and deployment options for these applications is high. For example, to discover simple processes that are running in a UNIX-based system, a user may use a command line tool, e.g., an instruction, such as UNIX command “ps” to “dump the process table,” for example. This command line tool creates a list of processes executing on a specific host on the network. The list may then be filtered using the UNIX “grep” command line with known search criteria. This specific methodology is, of course, of limited value as it is unable to discover non-running applications and does not discover the applications topology (i.e., the relationships among distributed components). More sophisticated tools, referred to as agents, may be built or created to probe still deeper into the components and their relationships. However, as in the prior example, there is no knowledge of what the relationships among multiple processes are, and only currently running processes may be discovered.
Thus, as the network expands it can become bloated with forgotten application packages that may have little or no usage, but are left in place as the consequence of their removal is unknown. On the other hand, leaving unused applications where they are installed may cause harm by consuming valuable disk space and/or if running, also consuming valuable CPU cycles. Most importantly, there are critical applications that must be running with optimal performance for a business to service their customers and effectively run their operation.
To manage the applications, whether active, active and forgotten, or not running, it is important to understand or have knowledge of the configuration of the application components. Application configuration information includes the description of the application, its components, the relationship between applications, the relationship between the components, and how the components are related with the underlying system and environment on which they are running. Examples of aspects of an application component include its structure at a device, its structure across devices, its performance characteristics, its dependencies with other applications in the device, and its dependencies with other applications in other devices. However, no systematic method exists to interrogate the network and determine applications residing on the network, and their status based on the discovered components.
Hence, there is a need in the industry for a systematic method and apparatus for discovering distributed application components and identifying the associated application topology.